While processing loops within application software (code), it is more processor and memory efficient to remove and load loop expressions in statements that will execute at least once outside the context of the loop. This permits such expressions to be resolved once and referenced as needed from locations outside the scope of the loop thereby providing more processor and memory efficient compiled code.
However, whether a statement will execute is sometimes not determinable at compile time, and thus such a statement may not be safely loaded outside the context of the loop statements. For example, in the statement “if A then X/Y,” A will be evaluated; but at compile time it cannot be determined whether or not “X/Y” will be evaluated. Moreover, it may not be safe to assume that “X/Y” will execute, because Y may be zero at runtime resulting in an error condition. The statement itself may therefore never present a problem within the loop, because A may never evaluate to true, such that “X/Y” will execute to produce the error. Statements for which it is not known whether they will execute at runtime are referred to as “invariant expressions.”
Two approaches have been attempted to safely load invariant expressions. The first is referred to as “profile-guided loop invariant code motion.” Here, profile information is used to compute probabilities that invariant expressions will execute at compile time. Yet, this approach cannot ensure that an invariant expression will execute; it only provides a probability that an invariant expression is likely or not likely to execute. The second approach is referred to “speculative loop invariant code motion.” With this approach, additional hardware support is used to check on load safety before statements are loaded.